Figure 14.7: CordApp

(Source: https://docs.corda.net/docs/corda-os/4.7/cordapp-overview.html)

Let’s find out how that can be achieved. In Corda, each node can be

accessed either using an RPC call directly or by calling it through an

HTTP request. Hence, each organization can run their REST

endpoints on a different URL with the help of a Spring Boot server

that internally invokes the corresponding node with an RPC call.

Once the request reaches the node, it can validate the data in the

request with smart contract, sign the transaction, share it with

counter party, and get their sign off, and finally get it validated by the

notary. If all goes well, the data can be stored on the respective

node’s vaults and the transactions get committed. The response can

be sent back either though the RPC call response or as an HTTP

response. Hence, it’s pretty simple to get the Corda nodes tested as

well as give a demo to the clients, showing them the actual changes

happening at the node level.

14.3 Corda End-To-End Transaction Flow

As shown in Figure 14.8, Corda flows are business processes

involving

multiple

point-to-point

communications,

Transaction

requests, data sharing, contract validations, notarization and ledger

updates, as follows:

Figure 14.8: Corda Transaction flow between parties

One flow may contain zero or more subflows where each subflow is

responsible for handling a particular subprocess.

Note: Unlike Fabric, there is no global broadcasting in Corda. All

data sharing are point-to-point and happens only when explicitly

done on need basis.